Description

An accounting Web application (youraccounting.safelayer.com) lets the user sign accounting entries made during a given period of time (e.g., a month) so that the period remains closed and cannot be modified. To do this, the Web application calculates the hash (SHA-256) of each entry made during this period after ordering them chronologically. The user can request generation of the evidences for several months (e.g., for a quarter) via the corresponding digital signatures. This requires using TRIDENT's digital signature API to obtain the signatures in PKCS #1 format for three months. I.e., a signature for each of the three hashes or groups of entries. The application lets the user obtain the signatures or stores them in a repository of evidences that contains the signatures of all the closed accounting periods.

The Web application is registered in TRIDENT as an OAuth 2.0 client application, which means it has an authorization server ( main ) and an identifier ( youraccounting ), and that it shares a secret with the platform ( secret ). The https://youraccounting.safelayer.com/oauth/callback was registered as the portal's only redirect URL.

The Web application on behalf of a user (john.doe ) who accesses the application from any browser and who has logged in after authenticating in a TRIDENT identity provider via password. We are assuming that the signature keys of the user are in one of a TRIDENT’s signature provider, i.e., that the signing identity used to sign the accounting entries is a signing identity on the server. We also assume that the signing identity has the accounting and sign labels.

The data is signed as follows:

1. The user is authorized

2. The signing identity is obtained

3. The hash of the data is obtained

4. A signature batch is generated from the hashes of the data

Authorizing the User

For the accounting entries to be signed, the user must give authorization for the portal to obtain their signing Identities and request the creation of a signature batch on their behalf. For the first task, the scope required (urn:safelayer:eidas:sign:identity:profile) must be configured in the authorization server so that it does not require any authentication requirement and that the user's authorization is considered implicit. For the second task, the scope required (urn:safelayer:eidas:sign:identity:use:server) must be configured in the authorization server so that it requires the user to be reauthenticated by executing a flow that prompts the user for a signature PIN (which is always requested as the flow disables SSO for this factor) and so that it considers that the user's authorization is implicit in this new authentication.

In all cases, when the user clicks on the button for requesting the signature (e.g., Close period), the Web application responds with the following HTTP redirect response (see the Obtain Authorization operation):

This causes the browser to send to TRIDENT the following HTTP request:

On receiving this request, TRIDENT authenticates the user by prompting for the signature PIN and, based on this authentication, if successful, it deduces that the user authorizes the website to access their signing Identities and request the signature on the user's behalf. Lastly, TRIDENT provides the Web application with the code that accredits this authorization and redirects the browser to the URL specified in the authorization request ( https://youraccounting.safelayer.com/oauth/callback ). This redirect causes the browser to send the following HTTP request to the application:

Next, the application uses the code it receives from the browser to request the corresponding access token (see the Obtain a Token operation):

Token finally obtained in the following HTTP response:

Obtaining the Signing Identity

To determine which signing identity must be used to sign the accounting period, the Web application asks TRIDENT to provide it with all the signing Identities of the john.doe user that have the accounting and sign labels. To do this, it makes the following HTTP request (see the Obtain User Signing Identities operation):

Note that the application does not have to specify in the request that the signing Identities must belong to the john.doe user because TRIDENT deduces this from the authorization token included in the request (i.e., the system knows which user granted the associated authorization token).

We also assume there is only one such signing identity, and the Web application receives the following response:

In the above response you can see that 12345678 is the identifier of the only signing identity that the john.doe user has access to and that it also has the accounting and sign labels. The Web application must manage both the case where no signing identity can be found that meets the query criteria and also when more than one meets the criteria.

Obtaining the Hash of the Data

Because the server signing operation is done using the hashes of the data to be signed, the Web application must obtain the hash (SHA-256) of the accounting records for each month to be signed. The TRIDENT system establishes no restriction on how this hash must be obtained. It is normally calculated using the library or framework functions for this purpose.

Let's assume that the base64 encoding of the hashes of the quarterly accounting entries to be signed are the following:

Generating the Signature Batch from the Hashes of the Data

Once the Web application has obtained the hash of each month to be signed and knows the signing identity to be used, it requests that the signatures be generated by sending the following HTTP message (see the Create a Digital Signature Batch on the Server operation):

Lastly, the TRIDENT system responds to the above request with an HTTP response message. The body of this message contains a JSON structure with the signatures property that contains the three signatures encoded in base64. The order of the signatures is the same as the order of the hashes in the request. For the sake of readability, the strings have been replaced with elipses: